Skip to content

Conversation

compiler-errors
Copy link
Member

Miscellaneous commits that I didn't really want to fold into anything else.

Fixes one theoretical bug with the fast path not considering polarity for T: !Sized bounds.

@rustbot
Copy link
Collaborator

rustbot commented Jul 2, 2025

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 2, 2025
@@ -34,13 +34,6 @@ pub(crate) fn codegen_select_candidate<'tcx>(
let (infcx, param_env) = tcx.infer_ctxt().ignoring_regions().build_with_typing_env(typing_env);
let mut selcx = SelectionContext::new(&infcx);

if sizedness_fast_path(tcx, trait_ref.upcast(tcx)) {
Copy link
Member Author

@compiler-errors compiler-errors Jul 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function shouldn't ever be reached -- we never do Instance::resolve on Sized.

@compiler-errors
Copy link
Member Author

@bors2 try @rust-timer queue

r? lcnr perhaps

@rust-timer

This comment has been minimized.

@rust-bors
Copy link

rust-bors bot commented Jul 2, 2025

⌛ Trying commit 91c53c9 with merge 227ec3b

To cancel the try build, run the command @bors2 try cancel.

rust-bors bot added a commit that referenced this pull request Jul 2, 2025
Fast path nitpicks

Miscellaneous commits that I didn't really want to fold into anything else.

Fixes one theoretical bug with the fast path not considering polarity for `T: !Sized` bounds.
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 2, 2025
@rust-bors
Copy link

rust-bors bot commented Jul 2, 2025

☀️ Try build successful (CI)
Build commit: 227ec3b (227ec3b415808af85fe11410d8e1b4d8349c32bc, parent: 71e4c005caa812a16fcb08d0bf1e6f1eda7c8381)

@rust-timer

This comment has been minimized.

predicate.kind().skip_binder()
&& trait_pred.polarity == ty::PredicatePolarity::Positive
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this has happened multiple times by now 🤔 forgetting the polarity is too damn easy right now 🤔

I can't really think of a good alternative apart from actually splitting ClauseKind::Trait and ClauseKind::NegTrait 🤔

removing the def_id etc functions on TraitPredicate to require trait_pred.trait_ref.def_id() instead feels really cumbersome and not that helpful 🤔 changing ClauseKind::Trait to have TraitRef and Polarity as separate fields so that we always have to use (_, _) could work but feels really ugly

anyways, not part of this PR

@lcnr
Copy link
Contributor

lcnr commented Jul 3, 2025

@rust-timer build 227ec3b

@lcnr
Copy link
Contributor

lcnr commented Jul 3, 2025

r=me after getting perf to work ☠️

@lcnr lcnr added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 3, 2025
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (227ec3b): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.2% [-0.2%, -0.2%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.2% [-0.2%, -0.2%] 2

Max RSS (memory usage)

Results (primary -2.1%, secondary -2.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.1% [-2.6%, -1.7%] 2
Improvements ✅
(secondary)
-2.0% [-2.6%, -1.3%] 2
All ❌✅ (primary) -2.1% [-2.6%, -1.7%] 2

Cycles

Results (primary 0.3%, secondary 0.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
1.7% [1.5%, 1.9%] 2
Regressions ❌
(secondary)
1.6% [0.6%, 2.5%] 2
Improvements ✅
(primary)
-1.0% [-1.1%, -1.0%] 2
Improvements ✅
(secondary)
-2.1% [-2.1%, -2.1%] 1
All ❌✅ (primary) 0.3% [-1.1%, 1.9%] 4

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 463.343s -> 462.134s (-0.26%)
Artifact size: 372.24 MiB -> 372.24 MiB (-0.00%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 3, 2025
@lcnr
Copy link
Contributor

lcnr commented Jul 3, 2025

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 3, 2025

📌 Commit 91c53c9 has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 3, 2025
@compiler-errors
Copy link
Member Author

@bors rollup

bors added a commit that referenced this pull request Jul 4, 2025
Rollup of 11 pull requests

Successful merges:

 - #142749 (Add methods for converting bool to `Result<(), E>`)
 - #143288 (Fix `x clean` with a fifo)
 - #143307 (Fast path nitpicks)
 - #143346 (update coherence example)
 - #143356 (use unsigned_abs instead of `abs` on signed int to silence clippy)
 - #143370 (remove redundant #[must_use])
 - #143378 (simplify receivers for some array method calls)
 - #143380 (Replace kw_span by full span for generic const parameters.)
 - #143381 (rustdoc: don't treat methods under const impls or traits as const)
 - #143394 (compiler: Document and reduce `fn provide`s in hir crates)
 - #143395 (Always use the pure Rust fallback instead of `llvm.{maximum,minimum}`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 9de211b into rust-lang:master Jul 4, 2025
10 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 4, 2025
rust-timer added a commit that referenced this pull request Jul 4, 2025
Rollup merge of #143307 - compiler-errors:fast-path-nitpicks, r=lcnr

Fast path nitpicks

Miscellaneous commits that I didn't really want to fold into anything else.

Fixes one theoretical bug with the fast path not considering polarity for `T: !Sized` bounds.
Kobzol pushed a commit to Kobzol/rustc-dev-guide that referenced this pull request Jul 4, 2025
Rollup of 11 pull requests

Successful merges:

 - rust-lang/rust#142749 (Add methods for converting bool to `Result<(), E>`)
 - rust-lang/rust#143288 (Fix `x clean` with a fifo)
 - rust-lang/rust#143307 (Fast path nitpicks)
 - rust-lang/rust#143346 (update coherence example)
 - rust-lang/rust#143356 (use unsigned_abs instead of `abs` on signed int to silence clippy)
 - rust-lang/rust#143370 (remove redundant #[must_use])
 - rust-lang/rust#143378 (simplify receivers for some array method calls)
 - rust-lang/rust#143380 (Replace kw_span by full span for generic const parameters.)
 - rust-lang/rust#143381 (rustdoc: don't treat methods under const impls or traits as const)
 - rust-lang/rust#143394 (compiler: Document and reduce `fn provide`s in hir crates)
 - rust-lang/rust#143395 (Always use the pure Rust fallback instead of `llvm.{maximum,minimum}`)

r? `@ghost`
`@rustbot` modify labels: rollup
jhpratt added a commit to jhpratt/rust that referenced this pull request Aug 18, 2025
…ix, r=davidtwco

Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.

This example should fail to compile (and does under this PR, with the old and new solvers), but currently compiles successfully ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=6e0e5d0ae0cdf0571dea97938fb4a86d)), because (IIUC) the old solver's `lazily_elaborate_sizedness_candidate`/callers and the new solver's `TraitPredicate::fast_reject_assumption`/`match_assumption` consider a `T: _ Sized` candidate to satisfy a `T: _ MetaSized` obligation, for either polarity `_`, when that should only hold for positive polarity.

```rs
#![feature(negative_bounds)]
#![feature(sized_hierarchy)]

use std::marker::MetaSized;

fn foo<T: !MetaSized>() {}

fn bar<T: !Sized + MetaSized>() {
    foo::<T>();
    //~^ ERROR the trait bound `T: !MetaSized` is not satisfied // error under this PR
}
```

Only observable with the internal-only `feature(negative_bounds)`, so might just be "wontfix".

This example is added as a test in this PR (as well as testing that `foo<()>` and `foo<str>` are disallowed for `fn foo<T: !MetaSized`).

cc `@davidtwco` for `feature(sized_hierarchy)`

Maybe similar to 91c53c9 from <rust-lang#143307>
jhpratt added a commit to jhpratt/rust that referenced this pull request Aug 18, 2025
…ix, r=davidtwco

Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.

This example should fail to compile (and does under this PR, with the old and new solvers), but currently compiles successfully ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=6e0e5d0ae0cdf0571dea97938fb4a86d)), because (IIUC) the old solver's `lazily_elaborate_sizedness_candidate`/callers and the new solver's `TraitPredicate::fast_reject_assumption`/`match_assumption` consider a `T: _ Sized` candidate to satisfy a `T: _ MetaSized` obligation, for either polarity `_`, when that should only hold for positive polarity.

```rs
#![feature(negative_bounds)]
#![feature(sized_hierarchy)]

use std::marker::MetaSized;

fn foo<T: !MetaSized>() {}

fn bar<T: !Sized + MetaSized>() {
    foo::<T>();
    //~^ ERROR the trait bound `T: !MetaSized` is not satisfied // error under this PR
}
```

Only observable with the internal-only `feature(negative_bounds)`, so might just be "wontfix".

This example is added as a test in this PR (as well as testing that `foo<()>` and `foo<str>` are disallowed for `fn foo<T: !MetaSized`).

cc ``@davidtwco`` for `feature(sized_hierarchy)`

Maybe similar to 91c53c9 from <rust-lang#143307>
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Aug 19, 2025
…ix, r=davidtwco

Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.

This example should fail to compile (and does under this PR, with the old and new solvers), but currently compiles successfully ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=6e0e5d0ae0cdf0571dea97938fb4a86d)), because (IIUC) the old solver's `lazily_elaborate_sizedness_candidate`/callers and the new solver's `TraitPredicate::fast_reject_assumption`/`match_assumption` consider a `T: _ Sized` candidate to satisfy a `T: _ MetaSized` obligation, for either polarity `_`, when that should only hold for positive polarity.

```rs
#![feature(negative_bounds)]
#![feature(sized_hierarchy)]

use std::marker::MetaSized;

fn foo<T: !MetaSized>() {}

fn bar<T: !Sized + MetaSized>() {
    foo::<T>();
    //~^ ERROR the trait bound `T: !MetaSized` is not satisfied // error under this PR
}
```

Only observable with the internal-only `feature(negative_bounds)`, so might just be "wontfix".

This example is added as a test in this PR (as well as testing that `foo<()>` and `foo<str>` are disallowed for `fn foo<T: !MetaSized`).

cc `@davidtwco` for `feature(sized_hierarchy)`

Maybe similar to 91c53c9 from <rust-lang#143307>
rust-timer added a commit that referenced this pull request Aug 19, 2025
Rollup merge of #145537 - zachs18:metasized-negative-bound-fix, r=davidtwco

Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.

This example should fail to compile (and does under this PR, with the old and new solvers), but currently compiles successfully ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=6e0e5d0ae0cdf0571dea97938fb4a86d)), because (IIUC) the old solver's `lazily_elaborate_sizedness_candidate`/callers and the new solver's `TraitPredicate::fast_reject_assumption`/`match_assumption` consider a `T: _ Sized` candidate to satisfy a `T: _ MetaSized` obligation, for either polarity `_`, when that should only hold for positive polarity.

```rs
#![feature(negative_bounds)]
#![feature(sized_hierarchy)]

use std::marker::MetaSized;

fn foo<T: !MetaSized>() {}

fn bar<T: !Sized + MetaSized>() {
    foo::<T>();
    //~^ ERROR the trait bound `T: !MetaSized` is not satisfied // error under this PR
}
```

Only observable with the internal-only `feature(negative_bounds)`, so might just be "wontfix".

This example is added as a test in this PR (as well as testing that `foo<()>` and `foo<str>` are disallowed for `fn foo<T: !MetaSized`).

cc `@davidtwco` for `feature(sized_hierarchy)`

Maybe similar to 91c53c9 from <#143307>
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Aug 20, 2025
…idtwco

Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.

This example should fail to compile (and does under this PR, with the old and new solvers), but currently compiles successfully ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=6e0e5d0ae0cdf0571dea97938fb4a86d)), because (IIUC) the old solver's `lazily_elaborate_sizedness_candidate`/callers and the new solver's `TraitPredicate::fast_reject_assumption`/`match_assumption` consider a `T: _ Sized` candidate to satisfy a `T: _ MetaSized` obligation, for either polarity `_`, when that should only hold for positive polarity.

```rs
#![feature(negative_bounds)]
#![feature(sized_hierarchy)]

use std::marker::MetaSized;

fn foo<T: !MetaSized>() {}

fn bar<T: !Sized + MetaSized>() {
    foo::<T>();
    //~^ ERROR the trait bound `T: !MetaSized` is not satisfied // error under this PR
}
```

Only observable with the internal-only `feature(negative_bounds)`, so might just be "wontfix".

This example is added as a test in this PR (as well as testing that `foo<()>` and `foo<str>` are disallowed for `fn foo<T: !MetaSized`).

cc `@davidtwco` for `feature(sized_hierarchy)`

Maybe similar to 91c53c9 from <rust-lang/rust#143307>
github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Aug 25, 2025
…idtwco

Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.

This example should fail to compile (and does under this PR, with the old and new solvers), but currently compiles successfully ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=6e0e5d0ae0cdf0571dea97938fb4a86d)), because (IIUC) the old solver's `lazily_elaborate_sizedness_candidate`/callers and the new solver's `TraitPredicate::fast_reject_assumption`/`match_assumption` consider a `T: _ Sized` candidate to satisfy a `T: _ MetaSized` obligation, for either polarity `_`, when that should only hold for positive polarity.

```rs
#![feature(negative_bounds)]
#![feature(sized_hierarchy)]

use std::marker::MetaSized;

fn foo<T: !MetaSized>() {}

fn bar<T: !Sized + MetaSized>() {
    foo::<T>();
    //~^ ERROR the trait bound `T: !MetaSized` is not satisfied // error under this PR
}
```

Only observable with the internal-only `feature(negative_bounds)`, so might just be "wontfix".

This example is added as a test in this PR (as well as testing that `foo<()>` and `foo<str>` are disallowed for `fn foo<T: !MetaSized`).

cc `@davidtwco` for `feature(sized_hierarchy)`

Maybe similar to 91c53c9 from <rust-lang/rust#143307>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants